CPP MOLE 2.0 grid implementation + error handling - #442

This is also the cause of the GitHub action build errors. Change line 159 in CMakeLists.txt to

add_custom_target(cpp_all_build DEPENDS mole_C++ tests_C++ examples_C++ tests_matlab_octave)

To separate the cpp build from the total build. Then the actions will pass.

If implemented, check to make sure this doesn't break the build sequence.

Ohh, see previous comments

should this be initialized to something?

If grid.n is wrong, reports grid.m

Should check if file is open before writing.

So the array1D is a stacked object with the error stack and the vector in one shot. Later, you assume the error stack is empty, and start copying and pasting this around.

There should be some check, somewhere, that the error stack is empty and the size of this is the size of a std::vector.

This needs a validation check the x and y are not 0, or something wierd.

And shouldn't the function break here if "isValid=False"?. Why keep building?

Same error as 2D, and should break out of function if grid is not valid.

Should be int &ErrorCode, but it still works?

I ran it though claude and this was it's response:

Confirmed — MOLEerr_print at [MOLE_Errors.cpp:158-162] does exactly that fallback: if err.errCode isn't a key in MOLE_errors_messages, it prints "Invalid MOLE Error code []". Now the full chain, precisely:

The by-value vs by-reference mismatch:

read_ErrorLog's signature ([MOLE_arrays.cpp:194]):

void array1D::read_ErrorLog(int ErrorCode, std::string &location, std::string &arrayName)
Only location and arrayName are references (&). ErrorCode is a plain int — a copy. Inside the function ([MOLE_arrays.cpp:198].

ErrorCode = topError.errCode; // writes to the LOCAL copy
location = topError.errLocation; // writes through the reference — caller sees this
arrayName = topError.paramError; // writes through the reference — caller sees this
ErrorCode = topError.errCode; mutates the function's own stack-local parameter. When the function returns, that copy is discarded — nothing propagates back to the caller. location and arrayName do propagate, because they're bound to the caller's actual variables via reference. So the function silently does 2 of its 3 "outputs" correctly and drops the third — which is easy to miss in review because the code reads as if all three behave the same way.

The caller, and exactly what your selection shows:

drainArrayErrors<ArrayT> ([MOLE_grids.h:162-169]):


template <typename ArrayT> void drainArrayErrors(ArrayT &a) {
    while (a.hasArrayErrors()) {
        int errCode;                              // <- line 164, uninitialized
        string location, msgparam;
        a.read_ErrorLog(errCode, location, msgparam);
        logGridErr(errCode, location, msgparam);
    }
}

int errCode; at line 164 (the line you have selected) is declared with no initializer — its value is indeterminate stack garbage until something writes to it. The call to read_ErrorLog looks like it should fill it in (that's clearly the intent, matching location/msgparam), but because the parameter is by-value, it never does. So by the time logGridErr(errCode, ...) runs, errCode still holds whatever bytes happened to be sitting in that stack slot — reading it at all is undefined behavior in the strict sense, and in practice it's just whatever leftover value was there.

Downstream effect: logGridErr(size_t errCode, ...) ([MOLE_grids.h:141]) takes size_t, so the garbage int gets converted (sign-extended/wrapped if negative) into some arbitrary size_t and pushed onto the grid's real, user-visible error stack — this is the stack that print_ErrorLog()/write_ErrorLog() actually report from. The location and paramError strings attached to that entry are correct (e.g. "nd2DGrid" and a real descriptive message), but the errCode field is nonsense.

Concrete trigger path: grid2D::validGrid() → buildOrCheck2DCoords → nd2DGrid logs a real error like MOLE_ERR_INVALID_ARRAY_SIZE onto the array's own private a_errs stack when, e.g., mismatched coordinate array sizes are detected. buildOrCheck2DCoords then calls drainArrayErrors(X) to move that error onto the grid's stack — and that's the exact call that goes through the broken read_ErrorLog. So the grid ends up "flagged invalid" correctly (that part uses a separate mechanism, setCheckedWithErrors/MOLE_ERR_GRID_FLAGGED_W_ERRS), but if a user calls print_ErrorLog() to find out why, instead of seeing MOLE_ERR_INVALID_ARRAY_SIZE with its real message, they see "Invalid MOLE Error code [garbage]" — the diagnostic that was supposed to explain the failure is destroyed in transit.

The fix is mechanical: change all three read_ErrorLog declarations (and Utils::read_ErrorLog, same bug at [utils.h:125]/[utils.cpp:84]) from int ErrorCode to int &ErrorCode, matching the reference pattern already used for location/arrayName right next to it.